With a one-input-one-output workflow, as supported by the prior art, color management was not typically required. Images were typically scanned by a professional operator using a single scanner producing a color representation, e.g., cyan, magenta, yellow, and black (CMYK) format, that was tuned to a single output device. Spot colors were handled either by mixing spot inks or by using standard CMYK formulas in swatch books. An accurate monitor display was not typically available. The system worked because the CMYK values that the scanner produced were tuned for the output device, forming a closed loop that dealt with one set of numbers.
More recently, the types of input and output devices have increased dramatically. Input devices include not only high-end drum scanners but also high-end flatbed scanners, desktop flatbeds, desktop slide scanners, and digital cameras. Output devices include not only web and sheetfeed presses with waterless inks, soy inks, direct-to-plate printing, and Hi-Fi color but also digital proofers, flexography, film recorders, silk screeners, color copiers, laser printers, inkjet printers, and even monitors that function as final output devices. The diversity of input and output devices vastly complicates the approach of a closed workflow as previously discussed. Thus, possible workflows may be associated with a many-to-many mapping of input devices to output devices.
The result is a potentially huge number of possible conversions from input devices to output devices. With an m-input to n-output workflow, one may need m×n different conversions from the input to the output. With the increasing diversity of input and output devices, the task of providing desired color conversions from input to output can easily become unmanageable.
Color management is a solution for managing the different workflows that may be supported between different input device and output device combinations. Color management typically supports an intermediate representation of the desired colors. The intermediate representation is commonly referred as a profile connection space (PCS), which may be alternately referred as a working space. The function of the profile connection space is to serve as a hub for the plurality of device-to-device transformations. With such an approach, the m×n link problem is reduced to m+n links, in which only one link is needed for each device. Each link effectively describes the color reproduction behavior of a device. A link is commonly referred as a device profile. A device profile and the profile connection space are two of the four key components in a color management system.
As based upon current International Color Consortium (ICC) specifications, the four basic components of a color management system are a profile connection space, a set of profiles, a color management module (CMM), and rendering intents. The profile connection space allows the color management system to give a color an unambiguous numerical value in CIE XYZ or CIE LAB color space that does not depend on the quirks of the plurality of devices being used to reproduce the color but instead defines the color as a person actually sees the color. (Both CIE XYZ and CIE LAB are color spaces that are modeled as being device independent.) A profile describes the relationship between a device's RGB (red, green, and blue) or CMYK control signals and the actual colors that the control signals produce. Specifically, a profile defines the CIE XYZ or CIE LAB values that correspond to a given set of RGB or CMYK numbers. A color management module (CMM) is often called the engine of the color management system. The color management module is a piece of software that performs all of the calculations needed to convert the RGB or CMYK values. The color management module works with the color data that is contained in the profiles. Rendering intents includes four different rendering intents. Each type of rendering intent is a different way of dealing with “out-of-gamut” colors, where the output device is not physically capable of reproducing the color that is present in the source space.
As a workflow becomes more complex, color management becomes more important to the user for managing colors of an image file as the image file flows from input (e.g., a scanner) to output (e.g., printer). A workflow utilizes four stages of color management that include defining color meaning, normalizing color, converting color, and proofing. Defining the color meaning includes determining if a profile is embedded in the content and defining a profile if there is no embedded profile. The workflow can then proceed with normalizing color to a working space (corresponding to a device independent color space) or with converting the color representation of the image file directly to the destination space. If the color is normalized to a working space, operations are performed in the working space, e.g., the user modifying selected colors in the working space. A color management system may then build a transformation table from the source profile and the destination profile, using the common values from the working space. Consequently the color management system can convert a source image to a destination image using the transformation table.
A substantial effort, resources, and money may be invested in an application that utilizes capabilities of color management supported by an operating system, in which the application utilizes an application program interface (API) to utilize these capabilities. In order to be competitive in the marketplace and satisfy demands by users, a color management system may be revised, adding new capabilities that can be utilized by the application. However, it is not typically desirable for the legacy application to support an advanced API set to access the new capabilities and enhancements if the application is already using a legacy API set for legacy capabilities and the advanced API set is not compliant with the legacy API set. Doing so would entail a large effort and cost in revising the application.
With the prior art, color management solutions do not typically support legacy applications or solutions when a new version of a color management system with a corresponding new API set is introduced. The new version of the color management system may offer new capabilities, enhancements, and resolutions (fixes) to problems of the legacy version by altering and/or embellishing the legacy API set or by replacing the legacy API set with an advanced API set. If that is the case, the legacy application may not be compatible with the advanced API set and thus not compatible with the new version of the color management system. On the other hand, it may be difficult and costly for the color management system to support both the legacy API set and the advanced API set, considering development and maintenance issues. It would be an advancement in the art to provide compatibility of a legacy API with a new color management solution.